[threading] Switch to a native implementation of LowLevelLifoSemaphore #2098
Conversation
CoffeeFlux
force-pushed
the
semaphore-native-test
branch
3 times, most recently
from
57adfa9 to
9215021
Compare
CoffeeFlux
added
the
NO-MERGE
|
Blocking merge until I have benchmarking numbers. |
lambdageek
changed the title
CoffeeFlux
changed the title
CoffeeFlux
removed
the
NO-MERGE
CoffeeFlux
force-pushed
the
semaphore-native-test
branch
from
9215021 to
ad3f6af
Compare
src/mono/mono/utils/lifo-semaphore.c
Outdated
There was a problem hiding this comment.
I think you have to use try_new or somesuch, which might not exist, to actually get null, vs. abort.
Systematic problem in runtime imho -- doesn't want to handle out of memory in many places.
src/mono/mono/utils/lifo-semaphore.h
Outdated
There was a problem hiding this comment.
Can we maybe drop the leading underscore:
Pro underscore: It means don't use that identifier, it is private, i.e. say foo, not struct _foo.
Con underscore: Consider what the C++ would look like.
src/mono/mono/metadata/threads.c
Outdated
There was a problem hiding this comment.
These lines could be combined.
In fact, you could just declare the function to be taking LifoSemaphore* and remove the cast.
You could also expose mono_lifo_semaphore_delete and save the call/jmp.
|
Still blocked on benchmarking, but hopefully it'll be resolved this week. |
CoffeeFlux
force-pushed
the
semaphore-native-test
branch
from
ad3f6af to
c025c07
Compare
This change is motivated on two main fronts. The first is maintainability - the current managed implementation is difficult to understand and I worry diagnosing any potential issues would be a massive time sink. The second is performance - the current implementation appears to suffer from significant lock contention when running the TechEmpower plaintext benchmark. My hope is that the simpler, cleaner native implementation here will avoid both problems, but I don't want to merge it until we have benchmarking data. However, even if the numbers are similar, I still think it's worth merging just from a maintainability perspective. The native LifoSemaphore implementation has only ever been tested on posix-like platforms, so Windows behavior is unknown. Currently the Windows implementation of LowLevelLifoSemaphore is very different, so unless we have need for the LifoSemaphore elsewhere in the runtime this isn't a concern. Many thanks to @filipnavara for the initial implementation.
CoffeeFlux
force-pushed
the
semaphore-native-test
branch
from
c025c07 to
eb1ecf2
Compare
|
Finally was able to run the TE benchmark with this PR, and the performance looks similar to before. Will merge regardless for maintainability, and if the lock contention issue remains it should be easier to investigate after this. |
CoffeeFlux
changed the title
ghost
locked as resolved and limited conversation to collaborators
5 participants
This change is motivated on two main fronts. The first is maintainability - the current managed implementation is difficult to understand and I worry diagnosing any potential issues would be a massive time sink. The second is performance - the current implementation appears to suffer from significant lock contention when running the TechEmpower plaintext benchmark. My hope is that the simpler, cleaner native implementation here will avoid both problems, but I don't want to merge it until we have benchmarking data. However, even if the numbers are similar, I still think it's worth merging just from a maintainability perspective.
The native LifoSemaphore implementation has only ever been tested on posix-like platforms, so Windows behavior is unknown. Currently the Windows implementation of LowLevelLifoSemaphore is very different, so unless we have need for the LifoSemaphore elsewhere in the runtime this isn't a concern.
Many thanks to @filipnavara for the initial implementation.